系列：30 天打造企業級 PLM｜面向：全端

問題場景

圖面、規格書、檢驗報告，PLM 一半的價值在檔案上。但掛檔案遠不只是上傳：檔案要跟著料號版本走（A 版的圖不能跟 B 版的混）、要有自己的版本（同一份規格書改了三稿）、下載要有權限（Day 6 的教訓），還要能接住舊系統搬來的幾 TB 附件。今天把檔案子系統一次講完。

商業邏輯設計

• 檔案跟著版本走。出貨追溯要的是當時那一版的圖面，所以附件掛在 ItemRevision 上而不是 Item 上，Day 3 模型的延伸：需要歷史的東西掛版本
• 舊系統附件只搬 metadata、實體檔案原地留用。幾 TB 的檔案搬遷是遷移計畫裡風險最高的一段（時間長、校驗難、失敗回退痛苦）；既然舊檔案庫的磁碟還在服役，就讓新系統唯讀直取，整段搬遷直接省掉
• 檔案權限的業務分級：機密圖面誰能下載。owner 與 shared users 的基本模型，配 Day 6 的認證底線

技術選型與取捨：儲存來源抽象化

架構演進：從 Agile File Manager Ticket 噩夢到儲存抽象層

在以前 Oracle Agile PLM 中，檔案子系統是一套獨立且脆弱的架構：

1. Agile File Manager（DFM）與 Ticket 驗證：檔案庫通常獨立跑在專屬 Tomcat 上，與 WebLogic 主伺服器透過專屬的 DFM 協定與 Ticket 機制驗證。只要兩台伺服器的時鐘（NTP）稍微偏差或 Ticket 逾時，使用者下載附件就會跳出 File Manager ticket invalid，導致全公司無法下載圖面；
2. 專屬協定難以整合：檔案在磁碟上的儲存格式高度特化，企業很難直接掛載現代的 S3 或跨廠區物件儲存。

Mini-PLM 採用儲存來源抽象化（Storage Provider）架構，底層支援 Local、S3 與外部唯讀 Vault，直接以標準 REST 串流下載，完全摒棄複雜的中介 Ticket 協定：

看實際的 mp_filedata 關鍵欄位：

mp_filedata
 file_name        varchar(256)
 storage_uuid     varchar(45)    ← 實體檔名（UUID，防猜測、防重名）
 storage_folder   varchar(10)    ← 分散目錄（避免單目錄百萬檔案）
 storage_source   varchar(20)    DEFAULT 'LOCAL'   ← 儲存來源：LOCAL / 外部 vault
 source_system    varchar(30)    ─┐
 source_file_id   varchar(100)    ├─ 外部來源的對應資訊（原系統檔案 ID、
 source_vault_id  varchar(100)   ─┘   所屬 vault——支援多廠區多檔案庫）

storage_source 是整個設計的樞紐。讀取端走 provider 介面，LOCAL 讀本地上傳目錄；外部 vault provider 依 source_file_id 換算出舊檔案庫的實體路徑（ID 補位、分層目錄規則，Day 24 附件對應鏈的執行版）唯讀取用。上層的下載 API、預覽、權限檢查完全不知道檔案實際住哪，新舊兩個世界在同一個下載連結後面無縫並存。

配套的安全規則：外部來源標記 SOURCE_READ_ONLY。在 Mini-PLM 刪除這筆附件，只移除關聯，永不動舊檔案庫的實體檔。那是舊系統的資產，新系統只是借閱者。

File Folder：檔案自己的版本控制

單檔掛附件之外，還有資料夾等級的需求：一包相關文件（規格書、測試報告、DFM 回饋）要一起改版。File Folder 三層模型：

mp_file_folder（資料夾）→ mp_file_folder_version（版本）→ mp_file_folder_file（版本內的檔案清單）

版本語意與 Item Revision 同款（Day 13 的思路複用）：發行過的資料夾版本不可變，改內容就開新版本；mp_file_folder_binding 把資料夾綁到業務物件（表單、品項）。同一套不可變版本的心法，這已經是第三次落地了：Item、Redline、File Folder。好的模型會自己長腳。

核心內容：下載授權的演進

Day 6 預告過的完整版。uuid 下載端點的演進分三階段。

階段 0 是原罪：匿名可下載，「知道連結就能拿」的內網習慣思維，storage_uuid 不可猜是唯一防線。階段 1：全面 authenticated()，離職員工的連結失效了，但任何登入者仍可下載任何檔案。階段 2（進行中）：檔案級授權，owner、sharedusers、所屬業務物件的權限傳遞，能看這張表單才能拿它的附件。

每階段都是發現然後收斂，不是一步到位。授權收緊是有既有使用者的系統最難的變更，每收一步都可能弄壞某人的工作流程，分階段讓每一步的影響面可解釋、可回退。

踩坑記錄

• 同檔多掛的刪除語意：一個實體檔被多個物件引用（同一份規格書掛在三顆料上），刪除必須只解關聯，實體檔的清理走引用計數歸零的獨立機制。「誰都不敢真的刪檔案」的癱瘓，來自刪除語意沒定義清楚
• 上傳目錄的分散設計要在第一天做。storage_folder 分散目錄，單一目錄塞十萬個檔案後，檔案系統的列舉與備份效能雪崩，事後搬移目錄結構是大工程
• 下載檔名的中文編碼：Content-Disposition 要走 RFC 5987（filename*=UTF-8''...），不處理的話中文檔名在不同瀏覽器各種亂碼

小結

儲存來源抽象化讓新舊檔案庫共用同一介面、外部唯讀；資料夾版本複用不可變模型；下載授權分階段收斂。明日 Day 26：批次匯入——三千筆料號怎麼優雅地進系統。